fix(index): make a crashed worker's log survive and name the run - #1644

The problem

Six open reports end at the same dead end. The supervisor contains a worker
failure, prints the log path, and the file is empty:

the worker log file mentioned (.worker-*.log) is completely empty (0 KB),
so I cannot identify which file caused the crash — #1145

• Windows-Indexing worker crashed on a file #1145 — Windows, exit_nonzero, 0 KB log
• Worker continuously hangs and indexing process gives up eventually #1130 — Windows, repeated hang + quarantine, "Worker logs are completely empty"
• Indexing worker can freeze the whole OS on binary-heavy folders, and always dies with a 0-byte log — needs resource guards and early log flush #1132 — resource guards; its ask feat: add Kotlin language support (.kt, .kts) #3 is exactly this
• index_repository: deterministic contained worker crash (0-byte log) when cache dir + derived project name exceed Windows MAX_PATH #1450 — Windows MAX_PATH: "the one diagnostic that would explain the failure is silenced by the failure itself"
• cross-repo-intelligence: --target-projects flag silently parses to zero targets; with raw-JSON args the worker crashes (0-byte log) #1133 — cross-repo-intelligence crash, "Worker log: 0 bytes"
• Index Error: outcome=killed exit_code=-1 signal=9 #1070 — Linux arm64, signal=9, empty log

Six reports, zero diagnoses. Not one is reproducible or attributable, and the
hint we print — "Indexing worker crashed on a file" — never names the file.

Root cause: buffering, not the crash

The supervisor redirects the worker's stdout+stderr into the log file
(options.log_file, subprocess.c), and every diagnostic reaches it through
fprintf(stderr, …) in log.c with no flush anywhere.

The C standard only promises stderr is "not fully buffered". The Windows CRT
gives a redirected stderr full buffering — which is why five of the six
reports are Windows. A worker that aborts, is SIGKILLed by the OOM killer, or is
terminated after a hang dies with its whole diagnostic still in a userspace
buffer. The file on disk is 0 bytes because nothing was ever written to it.

What this changes

cbm_log_set_crash_durable() — setvbuf(_IONBF) plus a per-line flush in
emit_line. Both, deliberately: setvbuf covers every writer to the stream,
including the plain fprintf(stderr, "CBM index worker could not start: …")
paths that explain a worker which never got as far as logging; the per-line flush
covers the case where setvbuf is refused because the stream was already written
to (it only binds before a stream's first operation). Enabled for the worker role
only, claimed in main() before the process writes anything.

cbm_index_worker_log_begin() — a startup header written and flushed as the
worker's first act: version, build fingerprint, pid, repo path, and the worker's
own arguments. It is a control record, not an info line, so a user running with
CBM_LOG_LEVEL=warn cannot end up back at a 0-byte log.

Per-file breadcrumb — under a crash-durable log the parallel extract pass logs
every file it starts, not just the first two rounds of workers, so the log ends
with the files that were in flight when the worker died. One line per file, never
per node. Behaviour is unchanged for every non-worker caller.

What a reporter now attaches instead of an empty file (real capture, worker
SIGKILLed mid-run):

{"level":"control","event":"index.worker.start","version":"dev","build":"0123…cdef","pid":"97197","repo_path":"/tmp/…/some repo","args":"{\"__cbm_test_worker\":\"buffered-kill\",\"repo_path\":\"/tmp/…/some repo\"}"}
level=info msg=mem.allocator.bound_populations_only owned_classes=0/6 populations=sqlite,tree_sitter …
level=info msg=mem.init budget_mb=24576 total_ram_mb=49152 source=ram_fraction
level=info msg=index.worker.buffered_kill_probe phase=before_kill

This fixes no crash. It converts six unreproducible reports into reports we
can act on, and every future one arrives with the run identified. That is the
whole claim — none of these six issues is closed by this PR.

Test

index_supervisor_killed_worker_log_is_never_empty_and_names_the_run
(tests/test_index_supervisor.c, suite index_supervisor).

A real worker child starts with a fully buffered stderr — the state the
Windows CRT hands a redirected stderr, forced on POSIX by the harness so the
contract binds on all three legs instead of being a Windows-only claim nobody can
run locally. It writes diagnostics and is then SIGKILLed. The supervisor keeps the
log of a failed worker, so what is on disk afterwards is exactly what a user would
attach to an issue. Asserted: non-empty, carries the header with version / pid /
repo path (containing a space, as Windows reporters have) / args, and still holds
the line written after the header.

The probe kills rather than aborts, and that mattered: Darwin's abort() runs
the stdio cleanup handler and flushes the very buffer the repro depends on
stranding. The first version of this test used abort(), and the reverted build
still produced a populated log — the repro was quietly toothless. SIGKILL cannot
be caught, blocked or handled, so no cleanup of any kind runs; it is also literally
#1070's death (signal=9) and how #1130's hung worker is terminated.

Revert-check — production change reverted (setvbuf + per-line flush + header
emission neutralised, test untouched), the log comes back at 0 bytes and the test
fails on the first content assertion. The harness dumps the log at the failure
site and it prints nothing at all:

  index_supervisor_killed_worker_log_is_never_empty_and_names_the_run
level=info msg=index.supervisor.reap outcome=killed exit_code=-1 signal=9
level=warn msg=index.supervisor.worker_failed outcome=killed exit_code=-1 log=/tmp/cbm-index-logheader-8VnBT2/logs/.worker-log-F42mK2
  [worker-dump] buffered-kill worker log: /tmp/cbm-index-logheader-8VnBT2/logs/.worker-log-F42mK2

  FAIL tests/test_index_supervisor.c:841: ASSERT(log_size > 0)

  6 passed, 1 failed

With the change in place, ./build/c/test-runner index_supervisor is 7/7 green
on macOS arm64 (ASan/UBSan build).